1. Field of the Invention
The present invention relates to a data processing system, and more particularly, to a data processing system which is constituted by a plurality of basic modules.
2. Description of the Related Art
Communications network systems involve a number of functional units such as signal transmission devices and switching subsystems. Those network elements are electronic systems which are generally composed of a plurality of circuit boards, or basic modules, each providing a specific function. Such a modular design allows maintenance people to repair the system easily when a failure occurs and some function is lost. This is actually accomplished by replacing a particular module that is relevant to the lost function. Although such replacement tasks seem simple, it is still possible for maintenance people to install a wrong module in place of the failed module, because they have to maintain and manage a large number of basic modules which constitute today""s complex electronic systems.
To avoid the above problem, researchers have proposed several management methods. One example of such proposals is Japanese Patent Laid-open Publication No. 7-219806 (1995), which discloses a method to avoid mounting of an inappropriate module by mistake. This is achieved by comparing two instances of property data of basic modules. More specifically, one set of property data is maintained in the management system, based on the modules mounting locations. This is compared with the other set of property data that is stored in each basic module""s identification data memory, thereby detecting erroneous installation of basic modules.
FIG. 21 is a diagram which shows a typical system configuration where the above-mentioned prior art method is employed. In this system of FIG. 21, the management system 1 monitors and controls each target system 30-1 to 30-n through a network 20. The network 20, which is configured as a data communication network (DCN) or the like, permits the management system 1 and target systems 30-1 to 30-n to communicate with each other. The target systems 30-1 to 30-n serve as network elements (e.g., transmission units, switches), each comprising a plurality of basic modules. Although not explicitly shown in FIG. 21, each basic module has a unique identifier in its storage portion to distinguish itself from others. When required, this information is supplied to the management system 1.
This management system 1 comprises a notification message parser 1a, a hardware change manager 1b, a failure record manager 1c, a system configuration database 1e, and a monitor console 1g. The notification message parser 1a receives various messages from the target systems 30-1 to 30-n and delivers them to relevant portions of the system 1, parsing the content of each message. The hardware change manager 1b becomes active when a basic module is replaced in any of the target systems 30-1 to 30-n. It retrieves information about the replaced module from the system configuration database 1e and displays it on a screen of the monitor console 1g. The failure record manager 1c, on the other hand, becomes active when a module failure has occurred in any of the target systems 30-1 to 30-n. It then retrieves information about the failed module, consulting the system configuration database 1e, and displays it on the monitor console 1g. The system configuration database 1e stores information on the mounting locations of basic modules constituting each target system, together with their identification data and the like. The monitor console 1g, which may be, for example, a cathode ray tube (CRT) display, visually presents information supplied from the hardware change manager 1b and failure record manager 1c. 
The above-described conventional system operates as follows. Now suppose that the target system 30-1 has encountered a problem with a certain basic module. The target system 30-1 detects this failure and notifies the management system 1 of the failure event and the properties of the failed basic module, along with the information for identifying the target system 30-1 itself. What are referred to here as the xe2x80x9cfailuresxe2x80x9d include recoverable failures and non-recoverable (or fatal) failures. In the management system 1, the notification message parser 1a receives and parses the notification message from the target system 30-1, recognizing that the received message is a failure notification concerning a specific basic module. Thus the message is passed to the failure record manager 1c. With reference to the basic module""s properties extracted from the message, the failure record manager 1c searches the system configuration database 1e to find information relevant to the failed module. This search yields more information related to the basic module, and the failure record manager 1c then displays it on the screen of the monitor console 1g, together with the information showing which target system holds the failed basic module.
In the way described above, the management system 1 permits the system administrator to readily find the target system and basic module in question. Further, since the screen presents the device name, vendor name, version number, and other information for identifying the failed basic module, the administrator can quickly understand which basic module should be replaced if the failure is unrecoverable.
The target system 30-1 to 30-n are designed to operate as follows, when a basic module is replaced. Suppose, for example, that a certain basic module in the target system 30-1 has been replaced with a new one as a result of deterioration or other causes of failure. The target system 30-1 then notifies the management system 1 of that module replacement. Also, the target system 30-1 sends property data read out of the new basic module, together with information for identifying the target system itself. This message is received and parsed by the notification message parser 1a in the management system 1. Finding that the message is intended for notification of replacement of a specific basic module, the notification message parser 1a supplies the information to the hardware change manager 1b. Based on the given information, the hardware change manager 1b searches the system configuration database 1e for data relating to the previously mounted basic module. The hardware change manager 1b also compares the new module with the previous one in terms of their module types (e.g., module name, vendor name, version number). If they do not agree with each other (or if the new module is not listed as a possible alternative to the previous module), the hardware change manager 1b displays an alarm message on the screen of the monitor 1g to alert that an inappropriate module is currently used in the target system 30-1. This allows the system administrator to readily determine whether the recent module replacement was properly performed or not.
The above-described conventional method, however, provides only a limited capability of module management. While the conventional method provides maintenance information about individual basic modules (e.g., which modules can be used for replacement), this may not always sufficient because the compatibility issues between one module and its related modules are lacking. Particularly, one could encounter a module incompatibility problem when trying to replace some module with another module from a different manufacturer or of a different version. That is, some replacement modules may not work together with other existing modules, because of the potential incompatibility between different vendor products or different product versions.
Taking the above into consideration, an object of the present invention is to provide a data processing system which checks the compatibility among basic modules used, so as to avoid any problems that could be caused by installation of inappropriate modules.
Another object of the present invention is to offer a data processing system which provides increased reliability of the entire system by continuously observing whether the system is properly configured with correct basic modules, and by pointing out a problem when a poorly compatible module is found.
To accomplish the above objects, according to the present invention, there is provided a data processing system that controls a plurality of basic modules as its constituent elements. This system comprises the following functional units: a failure detection unit which detects a failure of one of the basic modules; a data collection unit which collects property data of the failed basic module in response to the failure detected by the failure detection unit; a storage unit which stores the property data collected by the data collection unit, in association with an identifier that is to be used to identify the failed basic module; a processing unit which applies a predetermined process to what is stored in the storage unit; and an indication unit which shows the outcomes of the processing unit.